Config import from a different site fails because of shortcut.set.default.yml

I am not able to reproduce this issue.

@danylevskyi, what did you mean by "export configuration using a single file"? Did you import and export a "Full archive"?

Same problem as abobe I have got once try to run /usr/local/drush8/drush config-import staging -y

Same here http://dcycleproject.org/comment/2647#comment-2647

So it seems that the UUID of the default shortcut set does not match in your exported configuration and in your active configuration.

I was able to reproduce this with the following steps:

1. drush cex -y
2. Manually change the UUID in the shortcut.set.default.yml file of the exported configuration
3. drush cim -y

The question is how you got to the point of having different UUIDs in your configuration? Can someone post detailed steps starting from 0 how to reproduce this issue (without manually editing a config file, like above)?

@tstoeckler: YES your steps are fine to work-on but question is why *UUID* needs to change only for *short-cut* & *system.site* component, not for others?

Is it possible to import block_content to import? This is found that after full import the block content unable to import in the db, the import block is missing/showing broken in the original region see http://drupal.stackexchange.com/questions/146037/block-error-on-cmi

"Needs review" status is for a patch has been created and needs review and testing: https://www.drupal.org/issue-queue/status. There is no patch here.

I'm hitting this trying to import config into travis.
Some steps to reproduce:
1) Export all config
2) Create a new site with drush site-install
3) Find the site UUID of the original site, and set the site UUID of the new site to be the same with drush config-set "system.site" uuid
4) drush config-import

Problem is discussed here https://www.drupal.org/node/2638392. The solution suggested there:
drush ev '\Drupal::entityManager()->getStorage("shortcut_set")->load("default")->delete();'
works for me

I was experimenting with the Dcycle workflow combined with drush make.

I can confirm that this is still a problem in Drupal 8.1.3, and that drush command mentioned in #12 breaks my site, unless I un-install and re-install the Shortcut module.

So run these three commands to make config-import possible:

drush ev '\Drupal::entityManager()->getStorage("shortcut_set")->load("default")->delete();';
drush pmu shortcut -y;
drush en shortcut -y;

EDIT: Still a problem in Drupal 8.3.5 (August 2017), and only one command is actually needed:
drush ev '\Drupal::entityManager()->getStorage("shortcut_set")->load("default")->delete();'

Good idea if we can sync the configuration of e.g. short-cut & system-site programmatic way in hook_update
using

 \Drupal::service('config.factory')->getEditable('short-cut')->setData(array(
      // Here will be configuration structure & values.
    )
  )->save();

then run the drush cim

Updating Priority to Major, since this breaks the config-export > config-import workflow.

According to https://github.com/drush-ops/drush/pull/1875 and linked discussions, this can be fixed in many cases by either:
- specifying the minimal install profile (shortcuts come from standard); or
- using https://www.drupal.org/project/config_installer

I'm getting a similar error at same location:
Drupal\Core\Config\ConfigImporter->validate() (line 730 of
....../docroot/core/lib/Drupal/Core/Config/ConfigImporter.php).
The import failed due for the following reasons:
Unable to install the standard module since
it does not exist.

Looks like it is still some install profile related issue.

You could fix using Drupal Console, using 1.0.0-RC1 or superior

$ drupal entity:delete shortcut_set default

I cannot run the drush command because the error happens during drush site-install when I specify the folder to sync

drush si -y standard --config-dir=../config/sync

drush si -y standard

The standard installation profile automatically creates two shortcuts in standard.install
A workaround would be to create a custom installation profile where you don't create these two entities on install.

The actual issue comes from the configuration import mechanism which tries to purge and recreate fields if the UUID is different. See https://www.drupal.org/node/1613424 for more details.

Try to checkout what configuration yml files are displayed as will be deleted then edit every one and remove UUID line in the begin of each file. That works for me !

For my own purposes, I just replaced the UUID in the uuid: line of shortcut.set.default.yml with null (so the line reads uuid: null), and then everything worked fine, even with drush site-install --config-dir=../config/default (I'm using a project built with Acquia's BLT, alongside the Configuration Split module).

#6 worked for me. Thanks!!

#23 worked for me, thanks!

#23 no longer seems to work for me. Using drush 8.1.11 on latest drupal 8.3.x

Also, the downside of #23 is that even though you might successfully use "drush site-install standard --config-dir=config/sync" to install the site, once the site is up and you do a "drush config-export", it will update the shortcut.set.default config because now it has a non-null uuid in the site. If you commit this and push your config/sync to your repo, then another developer trying to pull this and run config-import will have trouble cause their uuid won't match.

Makes me wonder if the uuid stuff is causing more harm than good at this point.

Yeah, this is a pretty frustrating problem. I've decided to roll my own install profile to ship with our internal starter kit projects that does not include the shortcut module since we invariably never use it in projects.

This continues to be problematic for me on multiple sites. Is there any momentum toward at least defining a solution?

This pretty much blocks a "standard" site config from being re-installed (critical for building a site locally or working across a team).

This can actually be a duplicate of #2922417: Profile provided configuration entities can have unmeetable dependencies.

First, let me state my opinion that I think the default shortcuts should probably be outside of config altogether. This issue may be just an incremental fix to support previous installs that have already made use of shortcuts being in config. Maybe a separate issue can be created to remove offender(s) from core on new installs (it may exist, even). But, such discretional flexibility in Drupal's framework means this scenario will keep coming up because the Drupal framework does not prohibit items like shortcut.default from being in config (and there could be many other cases outside of the Shortcut example).

UUIDs should be able to be exported into a configuration target from an existing install and subsequently installed in a new site from a defined config directory.

The issue seems to suggest that a completely fresh "standard" install is created first, followed up by a subsequent config import of the defined directory is broken. This approach will fail repeatedly, due to this mismatch of UUIDs after the initial install re-creates configuration with it's own unique UUIDs in conflict to those stored in the existing config directory.

I see two possible problems here: 1. install, 2. after install. Install itself seems to be the primary blocker, as an initial install would at least respect the set of UUIDs imported initially (and, optionally, through the "--config-dir" directive as part of the site install command). After install would only break if, later, the UUIDs become mismatched (which I would hope would only be a result of a manual config change representing a discouraged practice in general).

Should this issue be morphed into fixing an initial site install to respect existing UUIDs? I think thats reasonable.

So this is related to #2914213: Don't create content in install hooks if module is installed during config import instead.

@jibran, as I understand the problem, this is not a duplicate of #2922417.

I think it is closer to #2914213 but it's hard to tell if they are solving the same problems or just related ones. I think they may be different. Both seem to refer to the issue of UUIDs and "content", e.g. the "shortcut.default" config. If content is installed after a site install using a new hook, does this actually solve the issue of the collision? I would suggest it would create the exact same error with the UUIDs colliding since the existing config will collide with the loading of content regardless of when it happens.

The more relevant issue seems to be that a site install seems to load the requested install profile configuration even if a configuration directory is supplied. Some solutions I see are:

1. turning off the UUID collision validation upon site install.
2. exploring conditional logic that checks if a "config-dir" is passed during site install, it overrides what is provided by the install profile (this makes the install profile selection basically invalid, to be honest).
3. core ships with a "load from configuration" profile that operates just like config_installer does. I sense that option 3 is the cleanest but this should be explored much further. I'm unclear on how "config-dir" would maintain support with profiles other than config_installer.

One related issue is around the "config_installer" based approach. By default, core seems to define the initial installed profile in settings.php. This breaks subsequent site installs with config_installer, because it throws an error for differing install profiles due to this hardcoded setting. My sense is that the installation profile config should not be written to settings.php by default (I am unclear on why this is desirable when it seems to be defined in the system settings config).

Valid for 8.5.x but drush ev '\Drupal::entityManager()->getStorage("shortcut_set")->load("default")->delete();'; helps.

We got the same issue when exporting using drush config export and import, between developers or environments, any idea how to fix this because a part from running drush ev, or editing the yaml to change the uuid to null. And we might forget or someone might waste time finding how to do this.

I think the only way to reproduce this issue is to use the --config-dir option with Drush 8 and the Standard profile. Now that Drush 9 is out (which doesn't allow you to use the --config-dir option with Standard) I don't think it can be reproduced.

You can use the config_installer profile to basically achieve the same thing as using --config-dir, and it works around problems like these automatically.

@nerdstein re the problem with config_installer changing the install profile - the best way around this I've found is to remove the install_profile key from settings.php entirely and then revoke write access. Drupal > 8.2.x doesn't need that value in settings and won't complain if it doesn't have write access.

I think this is basically by-design, caused by the fact that installing creates new UUID's. It might fail on shortcut having entities but that's a detail, the real issue is that such an import would delete and re-create every single config entity in the system.

If you want to do installs and then share the config, use something like config_installer. Maybe core in the future will change the installer to instead always install based on default config, which then might have uuid's by default, so that the default config is the same on all sites. But that might also have weird side effects.

In other words, duplicate of #2788777: Allow a site-specific profile to be installed from existing config, you're trying to solve the wrong problem IMHO.

@balsama I'm still getting this error with Drush 9 while using the config_installer profile

Ugh, just spent another hour working around this by forking standard into a new install profile on the fly.

I'm having this issue. Error when trying to import config via:
drush cim
or
drush cim -y
or
drush cim sync
is always:

 [error]  Drupal\Core\Config\ConfigImporterException: There were errors validating the config synchronization.
Entities exist of type <em class="placeholder">Shortcut link</em> and <em class="placeholder">Shortcut set</em> <em class="placeholder">Default</em>. These entities need to be deleted before importing. in Drupal\Core\Config\ConfigImporter->validate() (line 737 of /home2/auxcentra/public_html/dumdumproject/web/core/lib/Drupal/Core/Config/ConfigImporter.php). 

In ConfigImportCommands.php line 259:
                                                                                                                                                                                                   
  The import failed due to the following reasons:                                                                                                                                                  
  Entities exist of type <em class="placeholder">Shortcut link</em> and <em class="placeholder">Shortcut set</em> <em class="placeholder">Default</em>. These entities need to be deleted before   
  importing.   

Is it safe for me to delete this content from my local build or will that stop something working on my local(staging dev) build?

Assuming that it's safe to delete on localhost,
does that mean I would:
1. Delete the content that the Error suggests
2. re-Export from local: drush cex sync
3. update (commit / push it to my github repo)
4. re-pull to my cpanel
5. in SSH to Cpanel via CLI: drush cim sync
?
Is that the process to fix this error, or am I misunderstanding anything?

For me this is more issue about process, so I spent most of the time in drupal 7 exporting/importing DBs for content and config mainly (yeah, using features and db updates for everything on big sites is just too painful). So when D8 came I finally though ok I can have a site locally without exporting/importing DB, so I would naturally install some profile so I can have drupal site and then I would try to import config, of course this doesn't work and we have this other solutions for it, but I would bet many people will expect this to work like I described above. So even if this is by design I think it is not a good design, it is again usual "break your teeth on drupal way" design and think we should have on second step of installation, where you choose a profile, info about "if you want to install drupal site with existing config do/read this".

I'm also stuck with this, and find it rather inconvenient. Any thoughts/progress?

I'm on D8.8.2 and still the same issue. I find the configuration management more pain ... everytime you need logging and deleting the default shorcuts and then importing the configs!

I wonder when they will fix this painful issue? Any updates!

I think it isn't being fixed because some folks see it as an error on the part of those of us who aren't elite developers. I guess we're "doing it wrong". Well, if a large number of users seem to have a problem working with something, perhaps the "recommended process" is so badly designed that it desperately needs to be changed.

Here's part of the big problem. We can't install from configuration because of this issue:

https://www.drupal.org/project/drupal/issues/2982052

Meaning that we can't disable the shortcut module in core.extension.yml because the blt-installed empty site has default shortcuts in it. If we could install from configuration instead of importing configuration post-install, this wouldn't really be an issue.

We've tried blacklisting the file in config split and using config ignore. Neither of these things work with BLT setup.

https://docs.acquia.com/blt/developer/config-split/

langcode: en
status: true
dependencies: {  }
id: ci
label: CI
description: ''
folder: ../config/envs/ci
module: {  }
theme: {  }
blacklist:
  - shortcut.set.default
graylist: {  }
graylist_dependents: true
graylist_skip_equal: true
weight: 1

ignored_config_entities:
  - 'shortcut*'
_core:
  default_config_hash: UVH1aJ4b44UM-VdPVN7hNNuuVqfReJxwfVeDQH1Hvsk

Updated title and issue summary for more clarity around this issue, which still occurs. Leaving as major but I am not sure since there are workarounds? You already have to update the system.site UUID so this is just one other manual change.

I'm gettting this issue. Error when trying to import config via:

drush cim
or
drush cim -y
or
drush cim sync

 // Import the listed configuration changes?: yes.
 [error]  Drupal\Core\Config\ConfigImporterException: There were errors validating the config synchronization.
Site UUID in source storage does not match the target storage.
Entities exist of type <em class="placeholder">Shortcut link</em> and <em class="placeholder">Shortcut set</em> <em class="placeholder">Default</em>. These entities need to be deleted before importing. in Drupal\Core\Config\ConfigImporter->validate() (line 748 of ../D9/web/core/lib/Drupal/Core/Config/ConfigImporter.php).
In ConfigImportCommands.php line 357:
  The import failed due to the following reasons:
  Site UUID in source storage does not match the target storage.
  Entities exist of type <em class="placeholder">Shortcut link</em> and <em class="placeholder">S
  hortcut set</em> <em class="placeholder">Default</em>. These entities need to be deleted before
   importing.

also not able to import by Ui.

I just ran into this again, importing an existing site. I first have to set the UUID, delete the default shortcut, and then I can import the configuration:

$ drush config:set system.site uuid 0a1e7183-32bd-4cba-8411-f71ac6e08240 -y
$ drush ev '\Drupal::entityManager()->getStorage("shortcut_set")->load("default")->delete();'
$ drush config:import --diff -v -y

FWIW, and I'm not sure why, this IS an issue in drupal/core's standard but NOT an issue in Acquia Lightning. So there's something that Lightning did to resolve (or work around) this issue that could potentially be ported over here.

I'm 99% sure it's not about what Lightning did but what it _doesn't_ do. Creating default shortcuts. This happens when you have content for the bundles being re-created. shortcuts, nodes, terms, ...

As said several times before, this is just not how it is meant to work. What you're doing is basically re-installing the site, as you remove and re-create every config entity in the system, including fields. If you want that, install from config from the beginning, which is now natively supported with some limitations: https://www.drupal.org/node/2897299. Use that instead of installing and then re-doing everything.

@Berdir I agree, do you think this is works as designed?

No point in keeping open a major bug if the consensus is that it’s not a bug.

People hit this a fair bit, so maybe "Supprt request" captures the purpose of the issue now.

Fair enough, in that case it shouldn't be major.

I just hope that moving the goal posts doesn't reduce the urgency required to remediate this. Users are being told to use pipelines and blt to build sites. As it stands, this really doesn't work unless you go a-hunting in issue queues.

I think a lot of this problem could be fixed with #3159848: [Policy] Merge the minimal and standard install profiles into a starting point recipe.

Install from config is great, but it doesn't work if your config was installed from the standard profile, and that's what most people use.

We need an install profile that's a good base to start building from, but doesn't create superfluous stuff that prevents a config import.

FYI for people using Drupal 9

Replace:
$ drush ev '\Drupal::entityManager()->getStorage("shortcut_set")->load("default")->delete();'

with:
$ drush ev '\Drupal::EntityTypeManager()->getStorage("shortcut_set")->load("default")->delete();'

For who have Drush 9+ installed.

drush entity:delete shortcut_set

can solve the issue.

+1

 [error]  Drupal\Core\Config\ConfigImporterException: There were errors validating the config synchronization.
Entities exist of type <em class="placeholder">Shortcut link</em> and <em class="placeholder">Shortcut set</em> <em class="placeholder">Default</em>. These entities need to be deleted before importing. in Drupal\Core\Config\ConfigImporter->validate() (line 750 of /var/www/html/web/core/lib/Drupal/Core/Config/ConfigImporter.php). 

drush entity:delete shortcut_set resulted in a WSOD null error on toolbar menu.

Error: Call to a member function toUrl() on null in shortcut_toolbar() (line 343 of /var/www/html/web/core/modules/shortcut/shortcut.module)

Seemed to be fine after importing the new config.

> Error: Call to a member function toUrl() on null in shortcut_toolbar() (line 343 of /var/www/html/web/core/modules/shortcut/shortcut.module)

Because you deleted shortcut set, you want to delete shortcut.

Makes sense

Is there a workaround for this? Having same issue.

@emb03, there are two workarounds documented in the issue summary

This is an older thread, but just noting we ran into the same issues described here.

On D10 (v10.1.6), we attempted exporting/importing very basic site configuration from one dev site to another, but the workarounds described did not work. Notably, once shortcut_set (or shortcut per #71) is deleted, that causes failures in drupal core/shortcut where a "shortcut_set" object is expected to be not-null in a variety of places.

We abandoned the config export/import and used a db dump instead, which was fine for our short term need, but we were surprised that a simple configuration share didn't work.

I'm also facing this issue in D10.6
I'm working on CI pipeline and I want to import the config to a new Drupal site for testing.
My build always failed in this error.

This may shed some light on the issue. It seems to me that the full configuration for shortcuts (stored in the database tables) is not being exported to the config yml files.

The 3 attached screenshots show the three tables prefixed with "shortcut" in the site where shortcuts are working.

And here are the three config yml files exported from that site, and imported into another site (in which no shortcuts appear).

uuid: f2e2a04f-a646-4376-a5f0-78d157102f32
langcode: en
status: true
dependencies: {  }
_core:
  default_config_hash: U5VlGjd_SfV0Qm_EfnaynOfc549cNscFAx48JfYoMRI
id: default
label: Default

uuid: 9fbf3b51-f736-4160-9dbe-900d711b9ff8
langcode: en
status: true
dependencies: {  }
id: staff-shortcuts
label: 'Staff Shortcuts'

uuid: aa9e33ce-90ce-419c-bf91-c8b77f5b122e
langcode: en
status: true
dependencies: {  }
id: content-admin-shortcuts
label: 'Content Admin Shortcuts'

I just don't see how the data in the tables could come from the limited data in the yml files.

About 5 years ago the category was changed to Support request. And the core queue is not the best place for 'support requests'. The 'support request' option is there for filing support issues for contributed modules and themes. There are several support options listed on our Support page, including the Drupal Forums and Drupal Answers. There is also Drupal Slack.

There are also workarounds given in the issue summary.

I am closing this per the guidance in Handle or refer a support request in an issue.